13장. 개발자 도구의 캄브리아기 폭발 속 항해하기

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 13장 (pp. 272~287). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

IDE 하나를 평생 정착할 집처럼 고르던 시절은 끝났다. 채팅 어시스턴트·코딩 에이전트·IDE·챗봇 중 상황에 맞는 도구를 고르고, MCP로 AI에게 도구 접근 권한을 열어주는 법을 익히면 도구가 아무리 빨리 흥망해도 흔들리지 않는다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 개발 도구 생태계의 '멸종 주기'가 10년 단위에서 월 단위로 줄어든 이유를, 스티브의 이맥스·Intellij 전환 이력을 근거로 설명한다.
• 채팅 어시스턴트·코딩 에이전트·IDE·챗봇 네 가지 도구가 각각 우위를 점하는 상황을 구분하고, 진과 스티브의 실제 사례로 선택 기준을 정당화한다.
• MCP의 클라이언트-서버-툴 3요소 구조와 JSON-RPC 기반 요청·응답 메시지의 흐름을 설명한다.
• MCP가 왜 HTTP급 프로토콜에 비견되는지, 그리고 AI를 "지식을 가진 컨설턴트"에서 "실행하는 팀 구성원"으로 바꾸는 원리를 설명한다.
• 도구 격변기에도 흔들리지 않기 위한 6가지 항해 전략을 자신의 작업 방식에 적용한다.

전체 흐름도

§1 개발자 도구의 캄브리아기 폭발 — 집을 사던 시절은 끝났다
   IDE 정착(수십 년) → 운석 충돌 → 멸종 주기 월 단위
   스티브: 이맥스 30년 → Intellij 15년 → 혼용 5년 → 2025 초 일주일만에 이탈 → 2025 중반 복귀
                    │
                    ▼
§2 IDE vs. 에이전트 vs. 터미널 — 상황에 맞는 도구 고르기
   §2.1 코딩 에이전트 ── §2.2 채팅 어시스턴트(진의 CFP 사례) ── §2.3 IDE(인덱싱·결정적) ── §2.4 챗봇(진의 산책 브레인스토밍)
                    │
                    ▼
§3 도구의 격변 속에서 성장을 위한 원칙 — 에디터에 자아를 부여하지 않는다
                    │
                    ▼
§4 MCP로 AI와 다양한 도구 연결하기 — 파스타 제조기 비유
   §4.1 MCP란 무엇인가 → §4.2 스티브의 Puppeteer 게임 UI 사례 → §4.3 왜 MCP가 개발자에게 중요한가
                    │
                    ▼
§5 MCP 동작 원리 — 클라이언트, 서버, 서비스
   §5.1 아키텍처 → §5.2 RPC 메시지(JSON-RPC) → §5.3 FastMCP·list_tools() → §5.4 빠른 가이드
                    │
                    ▼
§6 결론 — 여섯 가지 항해 전략 · 다음 장(내부 개발 루프) 예고

0. 용어 사전

참고 — 위쪽 3개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 9장(주방과 AI 협업자 이해하기)을 먼저 보라.

1. 개발자 도구의 캄브리아기 폭발 — 집을 사던 시절은 끝났다

Intellij나 VS Code 같은 IDE를 고르는 일이 집을 사는 것과 같던 시절이 있었다. 한번 정하면 몇 년, 어쩌면 수십 년을 그 안에서 살아야 했다. 그 시절은 끝났다. 얽히고설킨 개발 도구 생태계에 거대 운석이 떨어져 캄브리아기 폭발이 일어난 것처럼, 하룻밤 사이에 수백 개의 AI 주도 개발자 도구가 나타났다 사라진다. 개발 도구의 '멸종 주기'는 이제 10년 단위가 아니라 월 단위로 측정된다.

스티브의 롤러코스터. 스티브는 30년 넘게 이맥스를 매일 사용했다. 15년 전부터는 작업의 반을 Intellij로 처리했고, 둘을 혼용하기까지 5년이 걸렸다. 2025년 초엔 단 일주일 만에 IDE와 이맥스를 거의 쓰지 않게 됐다가, 2025년 중반엔 다시 이맥스로 돌아왔다 — 이번엔 코드 편집이 아니라 에이전트 오케스트레이션 용도였다. 30년·15년·5년 단위로 흘러가던 전환 주기가 몇 달, 심지어 일주일 단위로 줄어든 것이다.

책을 쓰는 중에도 지형이 바뀌었다. 저자들은 집필 도중 OpenAI가 o4-mini 기반 코덱스를 출시하자 40분 동안 써 본 뒤, 7주 동안 애정을 쏟았던 클로드 소네트 3.7을 버릴까 하는 고민에 빠졌다고 고백한다. ChatGPT-3.5가 자신의 주력 언어로 함수를 짜냈을 때 놀랐던 것이 바로 얼마 전인데, 지금은 그마저 오래된 이야기가 됐다. 이런 속도로 도구가 진화한다면 앞으로 시도해야 할 도구의 숫자는 가늠할 수조차 없다. 저자들의 귀에 앤트로픽 개발자들이 CLI 기반 도구를 쓴다는 소식이 들렸을 때도 처음엔 이해가 가지 않았지만, 직접 써 보니 왜 그런 선택을 했는지 단박에 납득이 됐다고 말한다.

2. IDE vs. 에이전트 vs. 터미널 — 상황에 맞는 도구 고르기

소프트웨어 개발에서 쓸 수 있는 선택지는 챗봇, IDE에 통합된 코딩 어시스턴트, 독립형 AI 에이전트, 원격 에이전트, 그리고 터미널까지 다양하다. 저자들은 각 선택지가 우위를 점하는 자리를 이렇게 정리한다.

2.1 코딩 에이전트를 써야 할 때

단순하지 않은 작업에서는 저자 둘 다 코딩 어시스턴트나 에이전트를 쓴다. 코딩 에이전트는 작업을 완료할 때까지 자율적으로 실행을 반복한다. 반면 채팅 모드에서는 코드를 복사·붙여넣기 해야 해서 IDE·대화창·브라우저 등 여러 창을 오가야 한다 — 코딩 어시스턴트가 그 과정을 도와줘도 단계가 있는 상호작용이라는 점은 벗어날 수 없다. 에이전트는 채팅 대비 매우 효과적이어서 저자들은 가능한 모든 작업에 에이전트를 쓰지만, 모든 상황에서 에이전트가 최선은 아니라서 여전히 다른 방식도 함께 쓴다.

2.2 채팅 기반 코딩 어시스턴트를 써야 할 때 — 진의 CFP 버그 수정 사례

진은 수년 전 엔터프라이즈 테크놀로지 리더십 서밋(ETLS) 위원회가 CFP(발표 제안서)를 평가하는 솔루션을 개발했다. 회의 15분 전, 앱이 빈 화면만 보인다는 제보가 들어왔다. IDE를 켜고 재현해 보니 클로저로 작성된 서버에서 null pointer exception이 발생해 있었고, 스택 트레이스가 화면을 가득 채웠다. 진은 코딩 어시스턴트를 불러 스택 트레이스를 그대로 복사해 붙여넣고 "이 문제의 원인이 뭐야?"라고 물었다. 에러 관련 파일을 전부 콘텍스트로 쥐고 있던 어시스턴트는 원인과 해결책을 정확히 짚었고, 그대로 따라 하니 에러가 사라졌다. 진은 프로덕션에 코드를 푸시했고 위원회는 버그가 사라진 것을 확인했다 — 2분 안에 끝난 일이었다.

참고 — 지름길이 필요한 상황. 저자들은 진의 사례처럼 빠른 진단이 필요하거나, 코드베이스 파악·보일러플레이트 코드 생성이 목적일 때는 코딩 어시스턴트가 가장 빠른 지름길을 알려줄 확률이 높다고 말한다.

2.3 IDE가 여전히 우위를 점하는 분야

IDE는 수천 명이 수년간 쌓은 공학의 결정체다. 독자적인 분석 기술로 코드 전체를 분석해 인덱스를 만들고, LSP 같은 표준 프로토콜로 그 정보를 필요로 하는 곳에 제공한다. 인간의 IDE 사용 빈도가 줄어드는 바이브 코딩 시대에도, 그 인덱스는 인간뿐 아니라 AI에게도 코드베이스 탐색의 길잡이가 되기 때문에 IDE는 여전히 중요하다. 수백만 줄 규모의 코드베이스에서 대부분의 기업은 IDE와 코드 검색 시스템 조합이 최적의 선택이다(구글 같은 초거대 기업은 그 규모 때문에 클라우드 기반 인덱싱 시스템이 따로 필요하다).

IDE는 대규모 리팩터링을 수년, 수십 년에 걸쳐 정교하게 다듬어 왔고, AI와 달리 결정적으로 작동한다. 그래서 AI에게 직접 리팩터링을 지시하는 것보다, IDE나 대규모 리팩터링 도구를 쓰라고 지시하는 편이 난도·비용·정확도 모든 면에서 낫다. Intellij를 비롯한 일부 IDE는 MCP 서버 호스팅 기능을 지원해, 코딩 에이전트가 MCP 서버를 통해 리팩터링·디버거·프로파일러 같은 IDE 고유 기능을 직접 호출해 쓸 수 있다.

2.4 챗봇이 여전히 우위를 점하는 분야 — 진의 산책길 브레인스토밍

저자들은 여전히 ChatGPT를 쓴다. 진은 거의 매일 밤 아이패드 프로로 음성 모드 ChatGPT를 켠 채 개를 산책시킨다. 어느 저녁 "글 초안을 여러 번 작성할 때, 모델별 실행 횟수를 해시맵에 저장하는 변환 함수를 짜 줘"라고 요구하자 몇 초 뒤 구체적인 실행 계획이 담긴 답을 받았다. 진은 코드가 잘 작동하리라는 확신을 안고 다음 날 직접 구현할 생각에 들떠 잠자리에 들었다. 챗봇은 이렇게 24시간 상주하는 컨설턴트급 프로그래머로서, 밤낮 없이 브레인스토밍을 도와준다.

3. 도구의 격변 속에서 성장을 위한 원칙

툴 숙련도는 개발자 정체성의 큰 부분을 차지하고, IDE는 특히 사람들이 논쟁을 벌일 만큼 중요하다. 스티브는 이맥스에 대한 애정을 20년 넘게 블로그에 써 온, 가장 단호한 IDE 지지자 중 한 명이었다. 그런 저자들조차 앤트로픽 개발자 일부가 IDE 대신 CLI 기반 툴을 쓴다는 소식에 처음엔 감이 잡히지 않았지만, 클로드 코드를 직접 써 보고서야 개발자들이 완전히 새로운 방식으로 일할 수 있겠다는 생각에 자연스레 도달했다.

스티브는 한동안 이맥스와 영원히 작별했다고 여겼지만, 6개월 후 에이전트 오케스트레이션 용도로 다시 돌아왔다. 앞으로의 변화 속도는 지금까지와 차원이 다를 것이기에, 저자들은 이렇게 되뇌라고 권한다 — "에디터, 셸, 에이전트 프레임워크에 자아를 부여하지 말자. 진짜 자산은 수년간 쌓은 실무 경험과 직관이다." 격변의 시기에는 진짜 혁신과 단순 유행을 가려내기 어렵다. 모든 것을 다 시도해 볼 수는 없지만, 평이 좋은 새 도구는 신중하게 시도해 봐야 하며, 여러 사람과 경험을 나누고 비교하는 것도 좋은 방법이다.

4. MCP로 AI와 다양한 도구 연결하기 — 파스타 제조기 비유

주문 제작해 수십 년 써 온 파스타 면 제조기가 있다고 하자. 갓 입사한 수셰프에게 이 기계를 맡기면 제대로 다루지 못한다. 지구에 하나뿐인 이 기계를 쓰게 하려면 특별한 교육이 필요하다. AI도 마찬가지다 — 도구나 서비스를 활용하려면 그것에 접근하는 방법을 알아야 한다. 바로 이 지점에서 앤트로픽의 Model Context Protocol이 등장한다. MCP는 AI 어시스턴트를 위한 원격 직무 교육이라고 생각하면 이해하기 쉽다.

4.1 MCP란 무엇인가

MCP는 AI 에이전트가 외부 시스템과 연동하거나 도구·서비스를 호출해 실시간 최신 정보를 수집하도록 지원하는 규약이다. AI가 추론에 필요한 데이터나 툴 호출 결과를 콘텍스트에 포함할 수 있게 해, AI를 MCP가 없을 때보다 더 다재다능하고 인간에 가까운 기여자로 만든다. 시각적이고 상호작용이 필요한 업무도 맞춤형으로 수행할 수 있게 해 준다.

4.2 MCP 실제 사례 — 스티브의 Puppeteer 게임 UI 자동화

스티브는 자신의 게임 와이번에 쓸 노드/리액트 기반 단일 클라이언트를 구축하며, 기존 5개의 네이티브 클라이언트를 대체하려 했다. 이 작업을 제대로 하려면 AI 에이전트가 인간 개발자처럼 버튼을 클릭하고 폼을 채우고 메시지를 읽는 등 게임 클라이언트 UI를 직접 검사하고 상호작용할 수 있어야 했다. 스티브는 AI를 웹브라우저 자동화 도구 Puppeteer와 연결하는 MCP 서버를 설치했고, Puppeteer의 복잡한 내부 구조를 몰라도 MCP를 통해 다음과 같은 작업을 주고받을 수 있었다.

AI  → MCP: 클릭 명령(선택자: #login-button)
MCP → AI : 클릭 성공 보고
AI  → MCP: 텍스트 추출 명령(선택자: .welcome)
MCP → AI : "어드벤처에 오신 것을 환영합니다" 텍스트 반환

MCP는 이렇게 #login-button 같은 CSS 선택자로 HTML DOM 요소를 지정하고, AI가 그 요소를 대상으로 클릭이나 폼 전송 같은 작업을 스스로 수행하게 해 준다. MCP와 Puppeteer를 켜기 전과 후의 차이는 밤과 낮처럼 극명했다 — 마치 불을 켠 것처럼 AI가 세상을 볼 수 있게 됐다.

4.3 왜 MCP가 개발자에게 중요한가

이제 AI 에이전트는 사람의 특별한 개입 없이도 코드 작성 → 로컬 배포 → MCP/Puppeteer를 통한 상호작용 → 즉시 결과 확인까지 해낼 수 있는 수준에 이르렀다. 이는 빌드-테스트-디버그 사이클을 수십 배 단축시킨다 — FAAFO의 F(빠름)가 여기 해당하며, 동시에 더 다양한 선택지를 폭넓게 탐색할 수 있게 해 준다(옵셔널리티). MCP 같은 기술은 AI 어시스턴트를 진정한 협력 파트너로 발전시킨다. AI가 코드베이스를 넘어 데이터베이스와 실시간으로 정보를 주고받고, 외부 API를 호출하고, 애플리케이션을 제어하며, 거의 모든 디지털 도구·데이터 원천과 상호작용할 수 있게 지원하기 때문이다.

MCP를 통해 AI는 단순히 지식을 가진 컨설턴트에서 벗어나, 지시에 따라 복잡한 작업을 실제로 수행하는 유능한 팀 구성원으로 변모한다. 구체적인 구현 방법을 찾고 싶다면 깃허브에서 'model context protocol' 키워드로 검색해 보라고 저자들은 권한다.

5. MCP 동작 원리 — 클라이언트, 서버, 서비스

다양한 지표를 근거로 저자들은 MCP가 세계에서 가장 중요한 새 인터넷 프로토콜이 될 수 있다고 본다. 마이크로소프트 CTO 케빈 스콧은 "MCP는 의미적·철학적으로 HTTP와 동일한 수준의 중요성을 가진다. HTTP 덕분에 누구든 서버를 실행해 HTML 페이지를 만들고 원하는 콘텐츠를 인터넷에 공개할 수 있었다"라고 그 중요성을 강조했다.

5.1 MCP 아키텍처: 클라이언트, 서버, 서비스

MCP는 클라이언트-서버 아키텍처로 구성된다. MCP 클라이언트는 MCP 서버를 호출하는 AI 기반 애플리케이션이고, MCP 서버는 AI와 데이터 원천·툴 사이의 중간 다리다. 클로드 데스크톱, 클로드 코드, 소스그래프의 Amp, 커서 같은 대부분의 코딩 어시스턴트는 MCP 클라이언트라고 보면 된다.

참고 — MCP 호스트와 클라이언트를 혼동하지 말 것(옮긴이 주). MCP 호스트는 AI가 실제로 실행되는 환경(클로드·ChatGPT 같은 데스크톱 앱, VS Code·커서 같은 코드 에디터, CLI 툴, IDE 플러그인 등)이고, MCP 클라이언트는 그 호스트 안에서 MCP 프로토콜로 MCP 서버와 통신하는 역할이다. 하나의 앱이 두 역할을 동시에 하는 경우가 많아 혼동이 흔하다. 실무에서 'MCP를 연동했다'는 말은 대개 'MCP 서버를 연동했다'는 뜻이다.

MCP 호스트 및 클라이언트 (클로드, IDE, 툴)
        │  MCP 프로토콜         │  MCP 프로토콜
        ▼                      ▼
   MCP 서버 A              MCP 서버 B ── MCP 서버 C
        │                      │              │
   로컬 데이터 소스 A      로컬 데이터 소스 B    웹 API(인터넷) ── 원격 서버 B

(그림 13.1 MCP 사용이 가능한 시스템의 구조 예시 — 원문 재구성)

MCP 클라이언트라면 MCP 서버가 붙은 소프트웨어 전부와 통신할 수 있다 — MySQL/Postgres 같은 데이터베이스, 슬랙·줌 같은 API 지원 애플리케이션, AWS 같은 클라우드 서비스, 깃 같은 소스 관리 시스템, 센트리 같은 보안 제품까지. 서드파티 서버가 아니라면 바이브 코딩으로 직접 MCP 서버를 구축하는 것도 가능하다. MCP가 빠르게 시장을 점유하는 이유 중 하나는 단순함이라는 설계 철학이다.

5.2 MCP 내부 구조 — RPC 메시지

MCP의 핵심에는 RPC(원격 프로시저 호출)가 있다 — 다만 HTTP나 웹소켓 위에서 작동하는 통상의 JSON-RPC 2.0과는 쓰이는 맥락이 다르다. MCP의 구성 요소는 다음과 같다.

• MCP 클라이언트 — AI 어시스턴트
• MCP 서버 — 연결을 도와주는 중개자
• 툴 혹은 서비스 — 주방의 주문 제작 파스타 면 기기

AI를 도와 MCP 클라이언트가 MCP 서버에 다음과 같은 요청 메시지를 보낸다.

// AI → MCP 서버
{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": { "name": "fetch_weather", "arguments": {"location": "San Francisco"} }
}

요청을 받은 MCP 서버는 fetch_weather를 해석해 날씨 서비스 API 호출이나 DB 쿼리 같은 실질적인 작업으로 바꾸고, 다음과 같은 응답 메시지를 돌려준다.

// MCP 서버 → AI
{
  "jsonrpc": "2.0",
  "id": 42,
  "result": { "ok": true }
}

이 두 메시지가 AI에게 제공하는 '어휘'를 구성한다. 로그인·폼 작성·데이터 파싱 같은 상위 수준의 동작은 모두 이 기본 요소들을 이어 붙이는 것에서 비롯된다.

참고 — AI는 '로그인'을 이해하지 않는다(옮긴이 주). AI가 실제로 하는 일은 MCP 서버로 요청을 보내고 응답을 받는 것뿐이다. 로그인·데이터 조회·API 호출 같은 고수준 작업은 전부 이 요청·응답 메시지를 순서대로 이어 붙여 만든 워크플로의 결과다.

5.3 MCP 만들기: 기초 — FastMCP와 list_tools()

MCP 클라이언트는 SDK가 정의한 메서드로 MCP 서버가 제공하는 툴을 확인한다. FastMCP SDK에서는 list_tools()가 그 역할을 맡아, MCP 클라이언트가 서버가 지원하는 기능 목록을 받아 온다. MCP 서버는 fetch_weather(date) 같은 툴을 RPC 형태로 공개하므로, AI가 날씨 조회 같은 기능을 원격으로 호출할 수 있다.

MCP에서는 메서드를 정의하기만 해도 FastMCP 같은 프레임워크가 자동으로 타입 정보를 읽어 AI가 쓸 수 있는 툴로 등록해 준다 — 자바 서블릿이 메서드 정의와 애너테이션만으로 API 엔드포인트를 만들어 주는 것과 비슷하다. MCP 서버는 툴 제공 외에도 AI나 사용자를 위한 콘텍스트·데이터 같은 리소스, 그리고 프롬프트(템플릿 메시지·워크플로 등)도 함께 제공한다.

5.4 MCP 시작하기: 빠른 가이드

MCP는 단순함을 철학으로 설계됐다. 가장 좋은 출발점은 공식 사이트 ModelContextProtocol.io에서 예제를 따라 해 보는 것이다. 공식 예제는 단 4개의 함수(외부 기상 서비스 호출·위치 기반 날씨 반환·기상 경보 반환·출력 포매팅)만으로 날씨 정보를 가져오는 MCP 서버를 보여 준다. 서버를 구성한 뒤엔 간단한 설정으로 MCP 클라이언트에서 그 서버를 쓸 수 있다 — 설정 코드는 클라이언트마다 다르지만, 잘 모를 땐 AI 어시스턴트에게 물으면 어떤 파일에 무엇을 넣어야 하는지 알려 준다. 코딩 에이전트와 바이브 코딩을 할 때는 어떤 공개 MCP 서버를 붙여야 작업 환경에 맞는 최적의 효율을 낼지 항상 살펴야 한다.

참고 — MCP 서버는 권한을 위임하는 플러그인이다(옮긴이 주). 어떤 MCP 서버를 연결하느냐에 따라 심각한 보안 취약점이 생길 수 있다. 실무에서는 반드시 보안 스캐닝을 통과하고 신뢰할 수 있는 출처의 MCP 서버만 쓰고, 공식 저장소에 등록된 서버를 기준점으로 삼는 것이 안전하다.

6. 결론

개발 도구 생태계는 오랜 기간 안정적이던 기반암에서, 빠르게 움직이는 강 급류로 변모했다. 30년 쓰던 이맥스를 일주일 만에 버렸다가 몇 달 뒤 에이전트 오케스트레이션용으로 다시 쓰기 시작한 스티브의 사례, IDE에서 CLI 기반 도구로 옮겨 가는 앤트로픽 개발자들의 사례는 업계 전체가 비슷한 방향으로 대전환을 이룰 조짐일 수 있다. 가장 중요한 교훈은, 진짜 힘은 특정 도구가 아니라 풀고자 하는 문제에 맞춰 자신의 능력을 조합하고 환경에 적응하며 AI를 조율해내는 데 있다는 점이다.

개발자 도구 대폭발 시기를 헤쳐 나가기 위한 전략은 다음 여섯 가지다.

1. 에디터에 자아 부여 금지 — 진짜 자산은 수십 년간의 경험과 어렵게 얻은 직감이다. 이번 달 유행하는 도구가 무엇인지는 상관없다.
2. 상황에 맞는 적절한 도구 사용하기 — 자율적인 실행이 필요할 땐 에이전트, 빠른 진단이 필요할 땐 채팅 어시스턴트, 복잡한 탐색이 필요하면 IDE, 늦은 밤 브레인스토밍엔 챗봇이 좋다.
3. MCP를 범용 중개자로 받아들이기 — MCP를 쓰면 AI가 지식만 많은 컨설턴트에서 벗어나 유능한 실행자로 변모한다.
4. 적극적인 탐험가들과 네트워킹하기 — 새로운 도구라는 물살을 타는 다른 개발자들과 자주 노하우를 나눈다.
5. 탈출구 열어두기 — 주력 도구가 한계를 보일 때 우아하게 다른 도구로 넘어갈 수 있도록 여러 도구에 익숙해진다.
6. 새 도구를 배울 때 AI가 돕게 하기 — AI 어시스턴트가 충분한 지식을 가진 상태라면, 문서를 정독하며 시간을 낭비할 필요가 없다.

다음 장에서는 세 가지 개발 루프 중 첫 번째인 내부 개발 루프를 탐구한다 — 품질 유지를 위한 가장 중요한 기술 중 하나인 검증 및 확인 프로세스를 구축해, AI 수셰프가 주문한 그대로 요리하게 만드는 방법이다.

핵심 개념 정리

실무 체크리스트

• [ ] 지금 쓰는 도구를 "평생 정착할 집"처럼 여기고 있지는 않은가 — 멸종 주기가 월 단위임을 받아들이고 있는가?
• [ ] 단순하지 않은 작업에 여전히 채팅 창을 열어 복사·붙여넣기를 반복하며 스스로 병목이 되고 있지 않은가?
• [ ] 빠른 진단·보일러플레이트가 필요한 상황에서 무거운 코딩 에이전트부터 켜서 오히려 느려지고 있지 않은가?
• [ ] 대규모 리팩터링을 AI에게 직접 지시하는 대신, IDE나 리팩터링 도구를 쓰라고 지시하는 방법을 검토했는가?
• [ ] 에디터·셸·프레임워크에 자아를 부여해, 새 도구를 시도하기를 주저하고 있지는 않은가?
• [ ] 시각적·상호작용이 필요한 업무(UI 검사·폼 조작 등)에서 여전히 사람이 매번 화면을 설명하고 있지는 않은가 — MCP로 도구 접근 권한을 열어 줄 여지가 있는가?
• [ ] 새로 붙이려는 MCP 서버가 신뢰할 수 있는 출처인지, 보안 스캐닝을 거쳤는지 확인했는가?
• [ ] 주력 도구가 한계를 보일 때 다른 도구로 넘어갈 탈출구(대안 워크플로)를 열어 두고 있는가?
• [ ] 낯선 도구를 배울 때 문서를 처음부터 정독하는 대신, AI에게 먼저 설정 방법을 물어보고 있는가?

연습문제

1. 유형: 실무 시나리오. 새 프로젝트에서 반복적인 리팩터링(예: 함수 이름 일괄 변경)이 필요하다. 이 장의 §2.3(IDE가 여전히 우위를 점하는 분야) 원칙에 따라, AI에게 직접 리팩터링을 시키는 방법과 IDE 도구를 거치도록 지시하는 방법을 각각 설계하고 어느 쪽이 나은지 판단하라.
2. 유형: 판단. 다음 세 가지 작업 — ① 급하게 터진 프로덕션 버그의 스택 트레이스 진단 ② 하루 종일 걸리는 복잡한 마이그레이션 자동화 ③ 잠들기 전 새 기능 아이디어를 다듬는 브레인스토밍 — 각각에 이 장 §2가 제시한 어떤 도구(코딩 에이전트/채팅 어시스턴트/IDE/챗봇)를 배정할지, 그리고 그 근거를 설명하라.
3. 유형: 실무 시나리오. 진의 트렐로 스크린숏 자동화 아이디어처럼, 여러분이 반복적으로 다루는 GUI 애플리케이션(브라우저·데스크톱 앱 등)이 있다고 하자. §4의 파스타 제조기 비유와 스티브의 Puppeteer 사례를 근거로, 이 애플리케이션에 AI가 직접 접근하게 하려면 어떤 MCP 서버가 필요할지 설계하라.
4. 유형: 비교. §5.2의 RPC 요청·응답 메시지 구조(method·params·result)를 참고해, fetch_weather 대신 여러분의 업무에서 자주 반복하는 작업 하나를 골라 그 작업을 MCP 툴로 노출한다면 어떤 params와 result가 필요할지 설계하라.
5. 유형: 실무 시나리오. §3의 "에디터에 자아를 부여하지 말자"는 원칙과 §6의 "탈출구 열어두기" 전략을 근거로, 지금 주력으로 쓰는 도구가 갑자기 서비스를 중단한다면 어떤 대체 경로로 넘어갈지 개인 대응 계획을 세워라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 다룬 MCP 클라이언트-서버 구조와 "왜 MCP가 중요한가"라는 서술은 그대로 유효하다. 다만 MCP 자체의 거버넌스와 이 장이 예로 든 구체적 도구(Puppeteer 연결)는 책 집필 이후 크게 바뀌었다.

• MCP가 회사 소유물에서 업계 공유 표준으로. 이 장이 "MCP를 만든 앤트로픽"이라 부른 시점 이후, 앤트로픽은 MCP를 리눅스 재단 산하의 새 기구 Agentic AI Foundation에 기증했다(2025-12-09, 공식 발표) — 구글·마이크로소프트·OpenAI·AWS 등이 참여하는 벤더 중립 기구다. 이어 2026-07-28 스펙 개정이 나와, 이 장 §5.1이 설명한 클라이언트-서버 구조는 그대로 두되 프로토콜을 "상태 비저장(stateless)"으로 바꾸고 인증(authorization) 요건을 강화했다. 서버를 찾는 경로도 §5.4가 권한 "깃허브 검색"에서 공식 레지스트리로 정돈됐다(9장 최신 동향의 MCP 1주년 회고와 연결되는 같은 흐름의 후속 단계다 — 채택 통계는 9장 최신 동향을 보라).
• §4.2가 예로 든 Puppeteer 연결은 지금은 다른 표준으로 대체됐다. 앤트로픽이 공식으로 배포하던 Puppeteer MCP 서버(@modelcontextprotocol/server-puppeteer)는 2025-05-29 보관 처리(archived)되어 더 이상 유지되지 않는다. 지금 브라우저 자동화 MCP의 사실상 표준은 마이크로소프트가 공식 유지하는 Playwright MCP다 — Chromium 외에 Firefox·WebKit까지 지원하고, 스크린숏 대신 접근성 트리(accessibility tree)로 요소를 지정해 §4.2의 CSS 선택자 방식보다 더 안정적으로 작동한다. 스티브가 겪은 "불을 켠 것 같은" 경험 자체는 유효하지만, 지금 같은 작업을 한다면 다른 MCP 서버를 고를 가능성이 높다.
• §5.1이 예로 든 MCP 클라이언트 하나(소스그래프의 Amp)도 소속이 바뀌었다. Amp는 2025년 12월 소스그래프에서 분사해 독립 회사가 됐다(ampcode.com) — 이 장이 "소스그래프의 Amp"라 부른 시점의 소속 관계는 더 이상 유효하지 않지만, 도구 자체는 계속 운영되고 있다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• MCP 공식 사이트 — modelcontextprotocol.io
• MCP 를 리눅스 재단 Agentic AI Foundation 에 기증한다는 공식 발표 — Anthropic 공식 뉴스 · MCP 공식 블로그
• MCP 2026-07-28 스펙 개정 공식 발표 — Model Context Protocol Blog
• MCP 공식 서버 레지스트리 — registry.modelcontextprotocol.io
• Playwright MCP(마이크로소프트 공식, §4.2 Puppeteer 사례의 현재 대체 표준) — github.com/microsoft/playwright-mcp

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) §2.3에 따르면 IDE는 결정적으로 작동하고 수십 년간 다듬어진 인덱싱·리팩터링 능력을 갖췄으므로, 함수 이름 일괄 변경 같은 대규모 리팩터링은 AI에게 직접 시키기보다 "IDE의 일괄 이름 변경 기능을 사용해 이 함수 이름을 바꿔 줘"처럼 IDE 도구를 거치도록 지시하는 편이 난도·비용·정확도 모두에서 낫다. AI에게 직접 시키면 확률적으로 생성하므로 코드베이스 곳곳의 참조를 놓칠 위험이 있다.
2. (문제 2 정답) ①은 §2.2의 진의 CFP 사례처럼 채팅 어시스턴트에 에러 로그를 그대로 붙여넣는 것이 가장 빠르다(2분 만에 해결된 실제 사례가 근거다). ②는 §2.1의 코딩 에이전트가 맞다 — 단순하지 않고 자율 실행이 필요한 작업이기 때문이다. ③은 §2.4의 진의 산책길 사례처럼 챗봇(음성 모드 등)이 24시간 상주 컨설턴트 역할을 한다.
3. (문제 3 정답) §4의 파스타 제조기 비유대로, GUI 애플리케이션을 AI가 직접 조작하려면 그 애플리케이션 전용 MCP 서버(브라우저라면 §4.2처럼 Puppeteer나 최신 동향이 소개한 Playwright MCP, 데스크톱 앱이라면 그에 맞는 자동화 MCP 서버)가 필요하다. §4.2의 예시처럼 AI → MCP: 클릭 명령(선택자) / MCP → AI: 결과 보고 형태의 요청·응답으로 설계하면 된다.
4. (문제 4 정답) §5.2의 구조를 그대로 따르면, 예를 들어 "특정 파일의 최근 커밋 로그 조회"를 MCP 툴로 노출한다면 params는 {"file_path": "...", "limit": 10} 같은 형태, result는 {"commits": [...]} 같은 형태가 된다. 핵심은 AI가 이 요청·응답만으로 필요한 정보를 얻을 수 있어야 한다는 점이다.
5. (문제 5 정답) §3의 "에디터에 자아를 부여하지 말라"는 원칙에 따라 특정 도구에 대한 애착보다 문제 해결 능력 자체에 집중하고, §6의 "탈출구 열어두기" 전략에 따라 평소에도 대체 도구(예: 다른 코딩 에이전트나 채팅 어시스턴트)를 함께 익혀 둔다. 대응 계획에는 데이터·설정을 표준 형식으로 내보낼 수 있는지, 대체 도구로 전환하는 데 드는 학습 비용이 얼마나 되는지가 포함되어야 한다.